在上一篇文章中，分享了為什麼選擇 Terraform 當作主題，並解釋了什麼是 IaC（基礎設施即程式碼）。這篇文章，要探討 Terraform 是如何運作的！

Terraform 會透過雲端供應商（Provider）將程式碼指令，轉換成該雲端服務商可以理解的 API 呼叫，進而管理這些雲端資源。Provider 就像是翻譯官，將 Terraform 的統一語法轉換成各家雲端服務商專屬的 API 調用。這也是為什麼 Terraform 可以「一套語法管多雲」的關鍵✨

🐈🐈🐈

Terraform 的核心概念是透過配置檔案描述想要的基礎設施狀態，然後會自動計算並執行達成狀態所需要的操作。主要流程先看圖 👀✨

1. 編寫配置（Code）：這邊會使用 HCL（HashiCorp Configuration Language） 把想要的雲端資源（像是 VM、資料庫、網路）寫進配置檔案中。
2. 初始化（Init）：在開始前 Terraform 會先去下載「外掛程式（Provider Plugin）」，這樣它才知道要怎麼跟 AWS、GCP 之類的雲服務對話。
3. 規劃（Plan）：Terraform 會先檢查「現在雲端長什麼樣子」跟「我們設定檔裡想要的樣子」有什麼差異，然後列出一份「變更清單」，告訴你哪些東西會被新增、刪除或修改。
4. 應用（Apply）：如果變更清單看起來沒問題，我們就讓 Terraform 去執行，它會自動幫我們呼叫雲端 API，設定檔裡的內容變成真實的雲端資源。

這四個階段構成了 Terraform 的核心工作流程。當然，Terraform 還有其他輔助命令（像是 destroy（清除所有資源）、validate （檢查語法） 等），這些會在後續的實作文章中詳細介紹。

此外，還有一個貫穿整個 Terraform 運作的核心機制 —— 狀態管理！ 每個階段都依賴狀態管理來確保基礎設施的一致性。

Terraform 會維護一個叫 terraform.tfstate 的檔案，裡面記錄著雲端資源的實際狀態。每次執行 plan 或 apply 都會參考這個檔案，這樣它才知道哪些資源已經建好了、哪些需要更新，避免重複建立或誤刪資源。

狀態漂移（State Drift） 是常見的問題。比如有人直接透過 GCP Console 手動修改了 VM 規格，這時就會產生「實際狀態」與「記錄狀態」不一致的情況。Terraform 會在下次 plan 時偵測到這個差異，並提示該如何處理。

簡單來說，Terraform 的職責就是讓上圖三個圈圈的狀態保持一致！舉個簡單的例子：

假設有個情況是，在你配置的 main.tf 中期望狀態為：

resource "google_compute_instance" "web" {
  name         =  "my-web-server"
  machine_type =  "e2-small"
  zone         =  "asia-east1-a"
}

但實際上：

• 狀態檔案（terraform.tfstate）的記錄為：e2-micro
• 雲端實際存在的：e2-micro

這時 Terraform 會發現期望狀態跟實際不符，就會在 plan 階段告訴你「需要將 machine_type 從 e2-micro 改為 e2-small」。

總結來說，Terraform 的運作就是一個「描述期望 → 分析差異 → 執行變更 → 記錄狀態」的循環過程，透過狀態管理確保基礎設施始終與程式碼保持一致！

🐈🐈🐈

明白 Terraform 的運作流程後，下一篇要深入探討 Terraform 的組成元件，包括 Provider、Resource、Variable 等，更全面地理解 Terraform 的架構！